openmeter/ledger/collector/collection_fbo.go (1)

207-208: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Prefer slices.Contains for this new membership check.

Tiny cleanup: this is a plain slice lookup, so the standard helper fits better than lo.Contains. If you touch it, it’d be nice to align the nearby identical check too. As per coding guidelines, “Prefer standard library slices and maps helpers for common collection operations.”

♻️ Proposed direction

-		if len(route.Features) > 0 && !lo.Contains(route.Features, featureKey) {
+		if len(route.Features) > 0 && !slices.Contains(route.Features, featureKey) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openmeter/ledger/collector/collection_fbo.go` around lines 207 - 208, The
feature membership check in collection_fbo.go currently uses lo.Contains for a
plain slice lookup; switch this and the nearby identical route.Features check in
the same collection logic to the standard library slices.Contains helper. Update
the relevant condition(s) in the collector flow so the membership tests are
consistent with the coding guideline and no longer rely on lo.Contains.

Source: Coding guidelines

openmeter/ledger/customerbalance/service.go (1)

336-345: 🚀 Performance & Scalability | 🔵 Trivial | 🏗️ Heavy lift

Watch the new N+1 balance-query path.

This now calls GetSubAccountBalance once per matching sub-account during GetBalance. For customers with many feature/priority routes, that can turn a balance read into many DB-backed balance reads; a batched “balances by sub-account/route” query would keep the new allocability behavior without the round-trip growth. As per path instructions, “Anything related to event ingestion, message processing, database operations should be vetted for potential performance bottlenecks.”

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openmeter/ledger/customerbalance/service.go` around lines 336 - 345, The new
GetBalance loop introduces an N+1 database pattern by calling
GetSubAccountBalance once per matching sub-account in the subAccounts iteration.
Update the GetBalance flow in customerbalance/service.go to batch these lookups
through a single balances-by-sub-account/route query in BalanceQuerier, then map
results back to each subAccount while preserving the existing routeFilter and
allocability behavior. Use the GetBalance and GetSubAccountBalance paths to
locate the change and replace the per-item DB round trips with one batched
fetch.

Source: Path instructions

openmeter/ledger/collector/collection_fbo_test.go (1)

143-158: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Use the repo’s decimal assertion style here.

These expected values are simple integers, so require.Equal(..., Amount.InexactFloat64()) matches the test guideline and keeps failures a bit cleaner. As per coding guidelines, “When asserting alpacadecimal.Decimal equality in tests, prefer require.Equal(t, expectedFloat64, actual.InexactFloat64()) and simple float64(...) literals when precision allows.”

♻️ Proposed test assertion cleanup

-	require.True(t, alpacadecimal.NewFromInt(30).Equal(sources[0].Amount), "restricted source amount: %s", sources[0].Amount)
+	require.Equal(t, float64(30), sources[0].Amount.InexactFloat64(), "restricted source amount")
 	require.Empty(t, sources[1].Address.Route().Route().Features)
-	require.True(t, alpacadecimal.NewFromInt(10).Equal(sources[1].Amount), "unrestricted source amount: %s", sources[1].Amount)
+	require.Equal(t, float64(10), sources[1].Amount.InexactFloat64(), "unrestricted source amount")
@@
-	require.True(t, alpacadecimal.NewFromInt(10).Equal(unattributedSources[0].Amount), "unrestricted source amount: %s", unattributedSources[0].Amount)
+	require.Equal(t, float64(10), unattributedSources[0].Amount.InexactFloat64(), "unrestricted source amount")

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openmeter/ledger/collector/collection_fbo_test.go` around lines 143 - 158,
The test assertions in collectCustomerFBOForFeatureForTest are using
alpacadecimal equality directly for simple integer expectations, but the repo
prefers decimal assertions via float64 comparisons in tests. Update the checks
on the Amount values in collection_fbo_test.go to use require.Equal with
expected float64 literals against Amount.InexactFloat64(), including the
sources[0], sources[1], and unattributedSources[0] assertions, while keeping the
surrounding feature/length checks unchanged.

Source: Coding guidelines